Uma transação é uma unidade de trabalho

As alterações nos dados raramente chegam sozinhas: uma transferência tem de debitar uma conta e creditar outra, e um pedido tem de reservar stock e registar um pagamento. Se o sistema parar a meio, a base de dados fica a descrever um mundo que nunca existiu. Uma transação é a resposta da base de dados para esse problema — uma sequência de uma ou mais operações que a base de dados trata como uma única e indivisível unidade de trabalho.

Tudo, ou nada

Dentro de uma transação, cada operação pertence a um único resultado. A base de dados nunca expõe um estado final em que apenas parte da transação ocorreu. O exemplo clássico é uma transferência entre duas contas bancárias: reduzir o saldo da conta de origem e, em seguida, aumentar o saldo da conta de destino. Se apenas o primeiro passo fosse bem-sucedido, o dinheiro desapareceria; se apenas o segundo, o dinheiro apareceria do nada. Envolver ambos os passos numa única transação elimina as duas possibilidades.

Esta garantia de tudo ou nada chama-se atomicidade. Commit é o ato que torna permanentes as alterações da transação; uma transação que nunca faz commit não deixa qualquer vestígio. Durabilidade acrescenta a peça final: depois de o commit ter sido concluído, a alteração sobrevive mesmo que a máquina perca a energia um momento depois.

Uma transação é uma fronteira

Ajuda visualizar uma transação como uma fronteira traçada em torno de um conjunto de instruções. Antes da fronteira e depois dela, os dados cumprem as regras impostas pela estrutura. Dentro da fronteira existem estados intermédios — uma conta já está debitada enquanto a outra ainda não foi creditada — mas esses estados são privados da transação. As instruções posteriores noutras sessões não os tratam como a verdade.

Dois papéis ao mesmo tempo

Por isso, as transações desempenham dois papéis. O primeiro é o tratamento de falhas: se o processo falhar, a ligação cair ou uma instrução gerar um erro, a base de dados pode restaurar o estado que existia antes de a transação começar. O segundo é o controlo de visibilidade: enquanto o trabalho está em curso, os outros leitores ficam protegidos do resultado inacabado. Estes dois papéis estão relacionados, mas não são idênticos — a atomicidade decide se as alterações são mantidas, enquanto a visibilidade é regida pelo isolamento, a configuração que controla o quanto as transações concorrentes podem ver umas das outras.

Mantenha a unidade numa só ligação

O estado da transação pertence a uma ligação ou sessão, pelo que a instrução que abre a transação e o commit que a termina têm de ser executados na mesma ligação. Muitos drivers também funcionam em autocommit modo autocommit, em que cada instrução individual é a sua própria transação — uma unidade com várias instruções precisa do autocommit desativado ou de um início explícito.

Uma transação é uma unidade de trabalho

Envolver ambos os passos numa única transação elimina as duas possibilidades. Conceitos-chave: transação — uma sequência de uma ou mais operações executadas como uma única e indivisível unidade de trabalho.

QUESTÃO 1

Qual das afirmações descreve melhor uma transação de base de dados?

Uma sequência de uma ou mais operações tratadas como uma única e indivisível unidade de trabalho.

Um ficheiro de registo que grava todas as instruções que a base de dados já executou.

Uma cópia de segurança da base de dados feita antes de quaisquer alterações.

Uma única instrução SQL que altera uma linha.

QUESTÃO 2

Uma transferência debita a conta de origem e, em seguida, o servidor perde a energia antes de o crédito ser executado. A transação nunca fez commit. O que garante a base de dados quando reinicia?

Apenas o débito é mantido, porque foi executado primeiro.

O débito é mantido e o crédito é reaplicado automaticamente.

Ambas as alterações são mantidas, mas marcadas como incompletas.

Nenhuma das alterações sobrevive; a transação incompleta é desfeita durante a recuperação.

QUESTÃO 3

Qual é a diferença entre COMMIT e ROLLBACK?

São sinónimos; ambos tornam as alterações permanentes.

O COMMIT termina a instrução atual; o ROLLBACK termina toda a sessão.

O COMMIT torna permanentes as alterações da transação; o ROLLBACK descarta-as e deixa os dados como estavam antes de a transação começar.

O COMMIT armazena uma cópia dos dados; o ROLLBACK restaura essa cópia.

QUESTÃO 4

Um programador afirma: «Como a minha transferência é executada dentro de uma única transação, nenhuma outra sessão pode ver o débito antes do crédito.» Isto está correto?

Não, porque as outras sessões podem sempre ver dados não confirmados em qualquer base de dados.

Não; a atomicidade decide se as alterações são mantidas, enquanto a visibilidade é regida pelo isolamento, pelo que outra sessão pode ainda ler valores não confirmados dependendo do nível de isolamento.

Sim; a atomicidade esconde todos os estados intermédios de todas as outras sessões.

Sim, mas apenas se a transação for mantida muito curta.

QUESTÃO 5

Um commit é concluído com êxito e a máquina perde a energia um momento depois. O que garante a base de dados após a recuperação?

As alterações confirmadas continuam lá, porque a durabilidade garante que as alterações confirmadas sobrevivem a falhas e reinícios.

Apenas a última instrução da transação sobrevive.

A transação é revertida automaticamente após o reinício.

As alterações perdem-se porque a falha de energia ocorreu antes do próximo checkpoint.

Estudo de caso: A transferência interrompida

Leia o cenário abaixo e responda às duas questões.

Uma aplicação transfere 100 da conta 1 para a conta 2. Executa START TRANSACTION e, em seguida, UPDATE accounts SET balance = balance - 100 WHERE id = 1. Antes de o segundo UPDATE poder ser executado, a ligação de rede à base de dados cai e o processo da aplicação falha. A tabela accounts tem uma restrição check que mantém os saldos não negativos. Quando a aplicação reinicia, abre uma nova ligação e não encontra qualquer vestígio de a transferência ter sido concluída, e os saldos de ambas as contas continuam exatamente como estavam antes da tentativa.

Do ponto de vista da base de dados, o que acontece ao débito e qual é a garantia que o explica?

Resposta:
O débito nunca se torna um resultado final porque a transação nunca fez commit. Uma transação é uma unidade de trabalho, e a atomicidade significa que a unidade inteira é aplicada ou nenhuma parte dela é. Quando a ligação termina, a base de dados reverte a transação — ou realiza a mesma operação inversa durante a recuperação de falhas — restaurando o estado que existia antes de a transação começar. Não existe, portanto, nenhum estado em que 100 tenham saído da conta 1 sem chegarem à conta 2, pelo que nenhum dinheiro desaparece.

Mais tarde, a aplicação é refatorada para usar um pool de ligações. Porque é que o primeiro UPDATE e o commit têm de ser executados na mesma ligação ou sessão, e qual é o papel do autocommit?

Resposta:
O estado da transação pertence a uma ligação ou sessão, pelo que a instrução que abre a transação e o commit que a termina têm de ser emitidos na mesma ligação. Se uma camada de pooling encaminhar as instruções posteriores para uma ligação diferente, o commit aplica-se a uma unidade de trabalho diferente e a transação original fica aberta ou é revertida ao desligar, o que quebra a fronteira que a aplicação pretendia. O autocommit é importante porque a maioria dos drivers funciona em modo autocommit por predefinição, em que cada instrução é a sua própria transação; nesse modo, o débito tornar-se-ia permanente no instante em que fosse executado e não existiria qualquer unidade de tudo ou nada. Uma unidade com várias instruções exige, por isso, que o autocommit seja desativado ou que a transação seja iniciada explicitamente.